Some time ago, I wrote a post called “Is ASP.NET too difficult?” and I strongly believe that it is. Yet at the same time it cause problems by making it too easy to do relative advanced programming. It doesn’t seem to be a problem. On the contrary it appears to be a good thing, but an important thing is missing.

Step-by-step learning

Before ASP.NET when we used PHP and ASP, there was a certain step-by-step learning curve that everybody followed. You started out by learning basic HTML and then moved on to PHP/ASP. When you built your first projects it was time to learn about how to implement databases into them. When you mastered that, you were pretty good at building dynamic websites. This was the way that many of us took and it made us understand the platform before proceeding to more advanced features.

In ASP.NET there is no step-by-step learning in the old sense, because everything has become very easy. Database development has never been easier with all the wizards and easy-to-use ADO.NET features that handle it for you. It is more likely for an ASP.NET newbie to building database and AJAX driven websites before learning basic HTML or JavaScript.

From good to great

Still, that may not sound like a problem but I beg to defer. Because the previously difficult things have become very easy, it is no longer necessary to have a basic understanding of the request/response model of a web server or be concerned about how garbage collection works. You can still build good stuff.

From building good stuff to create great solutions is a huge leap. That will be much more difficult to be a great developer if you started out using all the wizards and other cheap tricks because you have to learn it all backwards. You really have to want it to begin reading books about basic programming techniques when you’ve just created a cool AJAX website without that knowledge.

Microsoft isn’t helping

This tendency to learn programming backwards is bad. The advantages are short lived and in the end, you have to pay the price. It seems that Microsoft is doing much to promote this backward learning by always doing their demos using the designer in Visual Studio. “Just drag n’ drop controls to your web page and it’s all great”. The designer cannot, I repeat cannot let you utilize the whole ASP.NET platform and all its features – far from it.

If you get stuck in the designer, you get stuck as a developer. I have never seen a professional web developer use the designer for other than personal hobby projects and there is a reason for that. It hides many decisions from you and leave them to the controls and wizards. The fewer decisions you are forced to make, the easier it becomes but as stated above, it comes at a price.

Make the decisions

This is the hard part. Before you are capable of making decisions based on your experience level, you have to know what the alternatives are. Otherwise it wouldn’t be a decision at all. Learn about the alternatives instead of leaving it to Visual Studio to decide. As Rocky Lhotka once said; developers are paid to think. What’s left afterward is code. Wise words.

Not all programmers want to take it further than as a hobby and that is perfectly fine. Just consider the consequences before taking the easy way. My advice is to throw away the designer and start writing code.

The built-in AJAX feature of ASP.NET 2.0, also known as Client Callback, is simple to utilize but a beauty in disguise. I’m not talking about the “Atlas” toolkit for ASP.NET but the ICallbackEventHandler interface that allows you to make asynchronous requests to server-side methods. It starts out being efficient and easy to use, but in the end of the website project, it will be slow and inflexible.

HTTP requests

If you trace the HTTP traffic of a Client Callback request, you will find that it sends way more than you need. I have a form that sends an asynchronous request whenever you check or uncheck a checkbox control. I would expect it to send the ID of the control and the value I give it, but actually it sends much, much more than that. To begin with, it sends the entire ViewState which could be huge. It also sends the value of many more controls than just the one I need. For the checkbox control that amounts to 10k.

POST vs. GET

It’s not a problem that it sends all the data, but it is impossible to turn it off and that’s a problem. Not only that, but the Client Callback feature only uses HTTP POST and that is slower than GET. There is no real practical reason to send POST requests – not for the developer’s side anyway – and it adds to the overhead.

All this simplicity (read overhead) is not worth it when you think of the alternatives. You could use Atlas instead or doing it manually with JavaScript and an HttpHandler. I prefer to do it manually or by a JavaScript framework like Prototype. In the case of the JavaScript framework, you still need the HttpHandler but the flexibility and performance is significantly better.

ActiveX vs. native

Another thing about the asynchronous request is that it does check for the ActiveX component before the native XmlHttpReqests object of the browser. That makes it slower in any other browser than IE6. If you do it manually, you can do it the other way around and gain performance that way as well. At the end of the day, there is not much fact talking in the favor the the Client Callback feature other than simplicity.

My experiences with the ICallbackEventHandler interface have made me turn to the alternatives. Even though ASP.NET is so easy in a lot of ways it is still important to know when things get too easy like in the case of Client Callbacks.